Fix idle wakeup problem #130
Conversation
|
If you don't close t.in, then of course this works just fine. I need to think about the implications of that -- if it only happens just before we exit(), then it won't be a problem, but I need to make sure we don't leak file descriptors -- e.g. if someone reinits the library. |
|
Yes that's true. This does cause a problem if you reinit the library. |
|
Could not really come up with a better option. I suppose most typical use of a terminal library is "one and done" (no reinit), but with that say it would be ugly to break that. Maybe it can be a flag/option for now, that's still an ugly contract but at least that put that choice on the library consumer? Of course if you find a different workaround that would be best, but the energy drain issue is sort of a show stopper for me (talking 2:30 hours of battery instead of 7 on my MBP). |
|
I'm astonished that this causes such a severe drain. There is indeed a better longer term solution. For now you can use this branch, and I will craft a better solution soon. Are you using this in MacOS X? Or Linux? Or something else? |
|
Yeah this is on OSX, I can try on linux if you wish. What's the long term solution you envision ? Just wondering, if that can be explained easily. |
|
Sorry, been working on other things. My thought is to use some of select or poll API with a second file descriptor, so that I can use that to wake the process. Its kind of an ugly hack, and I hate that I have to do this -- the root problem is that the terminal driver on MacOS (and presumably also BSD?) is crap. |
This PR should fix #129.
The way I fixed this is a bit of a hack but I think it works just fine. I changed
VTIMEto 0 andVMINto 1, but that causes thet.in.Read(chunk)call to block which in turn causes<-indoneqto block ort.in.Close()to block. So I put theRead()call in a separate goroutine which communicates to the normal input loop with a channel. WhenFini()is called, the channel is closed causinginputLoop()to return instead of hanging.I also had to get rid of the
Close()call ont.in(because it would block whileRead()blocks) which is less than ideal but I don't think it actually causes any problems becauset.inis read-only and the program terminates right afterwards.Also tcell now closes immediately instead of waiting 1/10th of a second.
Let me know what you think/if I created more problems than I fixed.